Черновик: DID-методы для ИИ-агентов и устройств (R5)

0. Имя метода — решить до реализации

Что уже используется в коде: did:scada:UUID-01 (примеры swagger), did:i:fl:<uuid> (персоны), did:i:is:identity-system (система identity), did:pki:ru:guc002 (пример parse). Отдельно: did:pki — уже зарегистрированный чужой метод (Attestto, 2026) для национальных УЦ (did:pki:<страна>:…), наш пример did:pki:ru:guc002 с ним совпадает по смыслу — использовать его для ссылок на российские УЦ можно, свой did:pki заводить нельзя.

Рекомендация: третий вариант. Ниже <m> — имя метода, примеры с ru как рабочим.

1. Синтаксис

did-m          = "did:" method-name ":" entity-type ":" entity-id
method-name    = "ru"                         ; рабочее, см. §0
entity-type    = "agent" / "device" / "org"
entity-id      = "z" 1*base58char            ; multibase base58btc
base58char     = %x31-39 / %x41-48 / %x4A-4E / %x50-5A / %x61-6B / %x6D-7A

entity-id — самосертифицируемый: multibase(base58btc) от SHA-256 канонического JWK (RFC 7638, уже есть didkey.Thumbprint) первого ключа из capabilityInvocation начального документа. Следствия:

• привязку DID к ключу проверяет кто угодно без реестра — по первой ревизии;

• идентификатор не зависит от хранилища: переход PostgreSQL → HLF не меняет ни одного DID;

• в идентификаторе нет ни серийного номера устройства, ни реквизитов организации (приватность, стабильность при смене данных). Серийный номер — в VC паспорта (InstrumentPassportCredential).

Пример формы: did:ru:agent:z<base58btc от 32 байт SHA-256> (≈44 символа после z).

2. Операции

Транспорт — HTTP API did-svc (/api/v1/dids), подпись операции — заголовок DID-Operation-Proof (compact JWS, claims {op, did, prevVersionId, bodyDigest, iat}). Подробно — сценарий did-svc/docs/scenarios/did-signed-operations.md.

Для агента и устройства: owner — DID зарегистрированной организации; создание подписывает она. Передача владения — два шага (добавить новую организацию в controller, затем она ставит себя owner).

DID URL

3. Отношения ключей для агента

4. Безопасность

• Приватные ключи в did-svc не попадают: приватные поля JWK отклоняются, подписи — на стороне клиента (KMS/HSM/CSP).

• Повтор операции невозможен: подпись привязана к версии; iat ограничивает окно.

• Захват документа: полномочия берутся из сохранённой версии, а не из присланной.

• Подмена истории в БД: хэш-цепочка + восстановление документа из подписанного тела; полностью — после якорения headDigest в HLF (проект R4).

• Компрометация ключа агента: владелец удаляет ключ из документа (Update своей подписью) или деактивирует DID; старые подписи остаются проверяемыми по истории.

• ГОСТ Р 34.10-2012 (L3): didproof.Verifiers.Register с проверкой на стороне PKI-сервиса.

5. Приватность

• В DID Document — только ключи, отношения, controller/owner и service endpoints. Реквизиты организации, ФИО, серийные номера — в VC, не в DID.

• owner раскрывает, какой организации принадлежит агент/устройство — это осознанно публично (ответственность владельца). Если раскрывать нельзя — вместо owner использовать VC-мандат.

• Самосертифицируемый entity-id не несёт сведений о субъекте.

6. Регистрация в W3C (если понадобится)

PR с файлом methods/<m>.json (name, status, specification) в w3c/did-extensions, автопроверка формата, AI-предревью спецификации по чеклисту, 2 одобрения мейнтейнеров, 7–30 дней. Для внутреннего использования регистрация не нужна.

Что сделать по итогам обсуждения

1. Выбрать имя метода (§0).

2. Валидация синтаксиса и самосертифицируемого entity-id при Create (небольшая правка validateDID/CreateDocument: ~0.5 дня с тестами).

3. Параметр versionId в resolve.

4. Оформить этот текст как did-svc/docs/did-method.md на английском, если пойдём в реестр.

Журнал изменений